Where does this information belong?
This guide is for the questions that come up in almost every implementation:
- Does this belong to the whole product family or only one variant?
- Is this product information, company knowledge, or a QMS record?
- Should this live in a Data Collection, in the technical file, or simply as an attachment?
If you answer those questions correctly early, your setup becomes much easier to maintain.
Start with what you are actually doing
Before you ask where to click in CertHub, ask yourself which of the two things you are doing. CertHub can do a lot, but in the end it always breaks down to one of these two modes:
Mode 1 — Follow and execute a process defined by QM
You are running a controlled QMS activity: a complaint, a CAPA, an incoming inspection, a training, a supplier evaluation, or any other workflow your quality system defines.
In CertHub that means:
- SOPs and Work Instructions define the process.
- Templates with Input Fields (forms) capture the execution — one record per instance.
- QM Lists give you the overview of all those records.
If the information you are looking at is created by a QMS process, it belongs here. Do not place it in the Product Database just because it happens to relate to a product.
Mode 2 — Create records and documents about the product
You are building or maintaining the technical file. In CertHub that means:
- Enter data in the Product Database — structured into Knowledge Units and Knowledge Topics.
- Decide the right scope for each piece of data (see the next section).
- Generate Documents through Templates that reference the maintained data.
Documents are the presentation layer. They should not quietly become the real source of truth again. The data lives in the Product Database; the document displays it.
Deciding the scope (inside Mode 2)
Once you know you are dealing with product information, the next question is scope. Where in the Product Database does it belong?
| Scope | CertHub name | When to choose it |
|---|---|---|
| Company-wide | Global Elements | The information is independent of any one device (company address, glossary, general regulatory requirements). |
| Reused across several product lines | Data Collections | Multiple families and product lines pick from the same list (supplier list, manufacturing sites, shared contraindications). In the legacy Word/Excel era, people usually called these master lists. |
| Shared by all variants of one Basic UDI-DI | Product Family | A change should affect every child product (shared intended use, indications, common design assumptions). |
| One variant / UDI-DI | Product | The information differs by size, model, configuration, or market version and changing it should affect only this variant. |
| Attached evidence | External Data on the relevant object | A file you want to keep (PDF, image, drawing, legacy document) but that does not need to be structured data. |
| Presentation for the notified body | Templates and Documents | The purpose is to present maintained data in document form. The document references the data; it does not replace it. |
Quick scope checks
Global Elements or product information? Choose Global Elements when the content is not device-specific. Choose the Product Database when the content describes the device itself, its design, its risks, its controls, or its evidence.
Product Family or Product? Choose the Family if all variants share the same answer and a future change should affect every child. Choose the Product if the information differs by variant and changing it should affect only one.
Data Collection or Product Family? Choose the Family when the information belongs to one device family. Choose a Data Collection when the same entries are reused across different families and product lines.
QMS record (Mode 1) or technical documentation (Mode 2)? Choose Mode 1 when the item is created through a controlled QMS activity. Choose Mode 2 when the item describes the device, its design, its requirements, its risk management, or its verification and validation story.
Worked examples
Intended use for a sterilizer family with three chamber sizes
If the intended use is the same for all three sizes, keep it at the Product Family level in the Product Database.
Commercial name and UDI-DI for one size
Keep that on the Product, because it is variant-specific.
Supplier list used by more than one product line
Keep that in a Data Collection so several families can reuse it. (In the legacy Word era, this is what people called a master list.)
Incoming inspection of a delivery
That is a QMS activity — Mode 1. The process is defined by an SOP, the inspector fills out a Template with Input Fields, and the record appears in a QM List.
Applicable regulations and standards for the company
Keep those as Global Elements.
Evidence that one requirement meets a specific clause
Keep the requirement and the verification evidence in the Product Database (Knowledge Units and Knowledge Topics), not only in a company-wide list.
Risk analysis
Maintain risk information as structured product data at the Product Family or Product level, depending on whether it is shared. Do not keep a spreadsheet attachment as the real source of truth if the information needs to be reviewed and traced.
A Jira requirement with a linked test PDF
The requirement and its verification evidence belong in the Product Database. The full test PDF stays where it was created; CertHub holds a controlled evidence record with a link. See How do we connect product development and test reports?.
A simple setup order for new customers
If you are setting up CertHub for the first time, this order usually works best:
- Start with Guided Setup.
- Decide your product families based on Basic UDI-DI logic.
- Place shared content on the Product Family or in Data Collections.
- Keep variant-specific content on the individual Product.
- Keep QMS-generated content in SOPs, Templates with Input Fields, and QM Lists (Mode 1).
- Only after that, add extra fields or structure where your device truly needs it.
Recommendation
If you are unsure, make the decision based on scope:
- company-wide → Global Elements
- shared across many product lines → Data Collections
- shared across one family → Product Family
- specific to one product → Product
- created by a QMS workflow → SOPs, forms, and QM Lists
- only needed as attached evidence → External Data
Once that decision is clear, the CertHub module choice usually becomes obvious.